BEST AVAILABLE COPY 



(12) 



UK Patent Application 



(19) 



GB „„ 2 210 480„3,A 

(43) Date of A publication 07.06.1989 



(21) Application No 8819018.6 

(22) . Date of filing 10.08.1988 



(30) Priority data 
(31) 104280 



(32) 02.10.1987 



(33) US 



(71) Applicant 

Sun Microsystems Inc 

(Incorporated In the USA - Delaware) 

2550 Garcia Avenue, Mountain View, California 94043, 
United States of America 



(72) inventors 

William Van Loo 
John Watkins 
Robert Garner 
William Joy 
Joseph Moran 
William Shannon 
Ray Cheng 



(51) INT CL* 

G06F 12/12 

(52) UK CL (Edition J) 

G4A AMC ' 

(56) Documents cited 
US 0452138 B 

(58) Field of search 

UK CL (Edition J) G4A AMC 
INT CL* G06F 



(74) Agent and/or Address for Service 
Potts Kerr and Co 

15 Hamilton Square, Birkenhead, Merseyside, 
L41 6BR, United Kingdom 



(54) Flush support 

(57) Hardware and software improvements in workstations which utilize virtual addressing in multiuser operating systems 
with wrrte Sack caches, including operating systems which allow each user to have mu.tip '"^'^ pr6Sent 
invention supports data protection and the reassignment of virtual addresses within such a system. Multiple active 
processes have their own virtual address spaces, and an operating system is shared by those processes in a manner 
fnSSS?o user programs. Cache -Rush" logic 33 is used to remove selected blocks from the virtual 
addresses are reassigned. A cache hit detector is adapted to detect cache hits in the shared operating system across 
multiple active user contexts. 



FIG. I 

32 



C*er+ Futn Lege 



«nt« B** BcrtWi 

r, 





ConifOi Lofl-c 



St 
/ 



At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy 
This print takes account of replacement documents submitted after the date of filing to enable the application to comply 
requirements of the Patents Rules 1982. 



1/23 



210480 




2/23 



2 2 1 0 4 E 



CPU Bus Address 

VA(15:4) 



VA(16) 

Cache Address 



Cache Tags 

CX(2:0) 



Valid 



Supervisor Prot 




Cache 
Hit 



FIG. 2a 



3/23 



Virtual Addr ess Cache: 
Cache and MMU Protection V iolations 



2210480 



CPU Bus Controls 

Write Bus Cycle 



User Access 
(Function Code « 0x2) 



Cache Tags 

Write Allowed 



Supervisor Access 
Required 



Cache Controls 

Cache Hit 




FIG. 2b 



48 



Cache 

Protection 

Violation 



CPU Bus Controls 

Write Bus Cycle 



User Access 
(Function Code » 0x2) 



MMU Page Map Bits 

Write Allowed 



Supervisor Access 
Required 



MMU Page Valid 




30b 



FIG. 2c 



36 



MMU 

Protection 
Violation 



4/23 



32 



Context Reg 



Virtual Add ress Write pack Cache; 
ftridress Path 

CX(2:0) 



2 1 0 4 8 0 



Cach 
L 

Match In 

A in Din 



,33 



;he Flush W 
Logic A |^> 

n 



VA(27:4) 



11 



CPU 



VA(27:0) 




Daia 



MMU 



RA(27:13) 



27 



CX, VA(27:16) 



Cache Tags 



CX, VA(27:16) 



.23 



CPU VA OE 

\ 



Clk 



VAR -)> 



VAR 

CX, VA(27:16) 



VA(15:13) 



CX, VA(27:16) 



Hit 
and 
Fluth 

Match 



Ctl 



< 



x 



Sel 
VAR/VA 



VAR w 
MUX VAR/VA 



45 



CX 

VA(27:13) 



CX, VA(27:16) 



RA(27:13) 



CJk RAR 



51 



Real Adr Reg 



RAR(27:13) 




To CPU Adr/Oata Bus 



FIG. 3 



5/23 



2210480 



Virtuol Address Coche: Address State Mochine 



Gate (a) 



Gate (t.m) 



MUX;Sel CPU YA 
Assert Cache TegQE 



MUX:Sel CPU YA 
Assert Cache Tog OE 
Translate CPU YA 



State <a) 



State (c) 



Assert Bus Ack to CPU 
Assert Bus Retry to CPU 
MUX: Sel CPUYA 
Assert Cache Tag OE 
CI k Tag YA to YAR 
Translate CPU YA 



State 
(e.») 





Gate (e.m) 




MUX: Sel CPUYA 
Translate CPU YA 



State 



Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Set Prot Yiol bit in 
Bus Error Reg 
MUX: Sel CPUYA 
Assert Cache TagOE 
ClkTsg YA to YAR 
Translate CPU YA 



MUX; Sel CPUYA 
ClkCPU Adr in RAR 
Translate CPU YA 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



State <g> 



State 
(e.v) 



Assert Bus Ack to CPU 
MUX: Sel CPUYA 
Assert Cache Tag OE 
CI k Tag YA to YAR 
Translate CPU YA 




State 
(e.h) 



Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Set Prot Yiol bit in 
Bus Error Reg 
MUX:Sel CPUYA 
Translate CPU YA 
Deassert Mem Adr Strobe 



State 

(i.v) 



FIG. 4a 



> 



6/23 



22104EQ 



G#to 



MUX:Sel YAR 
Translate Cache YA 
Assert CPU YAOE 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



MUXiSel YAR 
Translate Cache YA 
Assert CPU YA OE 
Update Cache Tags 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



MUXiSel YAR 
Translate Cache. YA 
Assert CPU YA OE 
Assert Mem Adr Strobe 
Assert Cache to MemOE 



State (1-b) 



State (k) 



State («) 




MUX: Sel YAR 
Translate Cache YA 
Clk Adr to RAR (at p) 
Assert CPU YA OE 
Dessert Mem Adr Strobe 



State (a) 



MUX:Sel YAR 
Translate Cache YA 
Assert CPU YA OE 



MUX:Se1 YAR 
Translate Cache YA 
Assert CPU YA OE 
Clk YA to YAR (ats) 



MUX:Sel YAR 
Translate CPU YA 
Assert CPU YA OE 



State <«> 



State (a) 



State (t) 




MUX:Se1 YAR 
Translate CPU YA 
Update MMU Statistic Bits 
Assert CPU YA OE 
Update Tag Yalid Bit 



State <v) 



Gata (a) 



J 



FIG. 4b 



7/23 



2210460 



virtual Afl rtrpss carhP Data Patn 



A(3)=0 
A(3)=1 



Cache Data O.E. 




To Real 
Adr Reg 



CPU Adr/Data Bus (63:0) 



/\/ /\J — Cache to Mem O.E. 



Hero Bus AD(63:0) 

(31:0) 



Mem toCacneO.E. 
(63:32) 



Main 
Memory 



D( 127:64) 



D(63:0) 



A(3)=0 
A(3)=l 



FIG. 5 



8/23 



22 A 0480 



virtual Ad*™**; Each* nnta State Mochine 




Assert CPU Write OE 



Assert CPU Write OE 




Deassert CPU Write OE 
Assert Bus Ack to CPU 
Assert Bus Error to CPU 



1 



Write CPU Data into Cache 
Deessert CPU Write OE 
Assert" Bus Ack to CPU 



State 
(i.vr) 



State 

(c.vr) 



State 

(e.w) 



State 



Assert CPU ReedOE 



Assert CPU Reed OE 



6 




eto (c.rm) 



N ^ Cache Protection 
Violation^ 



Deassert CPU ResdOE 
Assert Bus Ack to CPU 
Assert Bus Error to CPU 



Read Cache Date to CPU 
Deassert CPU ReadOE 
Assert Bus Ack to CPU 



State 
(a.rd) 



State 

(c.rd) 



State 

(e.rv> 



State 
(e.rfc) 



FIG. 6a 



9/23 



2210480 



Virtual Address Cache: Data ?««te Machine 



c 



Desssert CPU Write OE 
Assert Bus Ack to CPU 
Assert Bus Rretry to CPU 



Sttte 
(e.vi) 



Goto (c.rn) 



DeassertCPU Read OE 
Assert Bus Ack to CPU 
Assert Bus Retry to CPU 



State 

(e.rio) 



Assert Cache Date OE 




Sttte (g) 



Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Assert Cache Data OE 



State 

(i.v) 



c 



Gato (a) 



Assert Cache DetoOE 
CI *: Write Back Bufer 
Invert Cache Ad r bit A(3) 



I 



Assert Cache DetaOE 



State 



State (fc> 



Assert Cache DataOE 
Clk Write Back Bufer 
Invert Cache Adr bit A(3) 



State (») 




Null 



State 
(a.vt) 



Null 



Gate (n> 



State (a) 



FIG. 6b 



10/23 



2210480 



Virluol Addrea^ Coche: Doto Stole Machine 
(Write Bus Cgcle) 




Clk Data Reg 
Merge CPU Data vith 

Data Reg: 
Assert CPU Write OE 
Assert Data Reg 0E for 
Other Bytes 



Assert CPU Write OE 
Assert Data Reg OE for 
Other Bytes 
Update Data Cache 
Invert Cache Adr bit A(3) 



Gcta (« .r) 



SUte (q.v> 




State (s.v) 



G«to (•) 



FIG. 6C 



Clk Data Reg 
Deassert CPU Write OE 
Assert Data Reg OE for 
All Bytes 




Assert Data Reg OE for 
All Bytes 
Update Data Cache 



Assert Memory Busy 
Assert Start Write . 
Back Cycle 



State (a.v) 



State (v.v) 




State (g.v) 



11/25 



2210' 



Virtual Address Coche: Data State Machine 
(Rea4 Bw Cycle) 



^Gata («r)^ 



Clk Data Reg 
Assert CPU ReadOE 
Awcrt Date Reg OE for 
All Bytes 



Assert CPU Read OE 
Assert Data Reg OE for 
All Bytes 
Update Data Cache 
Invert Cache Adr bit A(3) 



State (q.r) 




State (s.r) 



Goto (a) 



FIG. 6d 



CI k Data Reg 
Deessert CPU Read OE 
Assert Data Reg OE for 
All Bytes 



N Mem 

ata Strobe 12, 



Assert Data Reg OE for 
All Bytes 
Update Date Cache 




Assert Memory Busy 
Assert Start Write 
Back Cycle 



State («. 




State (v 



State (y. 



12/23 



Write Bar* State Machine 




Assert Memory Busy 
Assert Memory Address Strobe 
Assert Cache to Memory O.E. 




Assert Memory Busy 
Deassert Memory Adr Strobe 
Assert Cache to Memory OE 



Assert Memory Busy 
Assert Memory Dote Strobe 0 

(First 64 bit transfer) 
Assert Cache to Memory O.E. 




Assert Memory Busy 
Deassert Memory Data Strobe 0 
Assert Cache to Memory O.E. 



Assert Memory Busy 
Assert Memory Data Strobe 1 

(Second 64 bit transfer) 
Assert Cache to Memory O.E. 




FIG. 7 



13/23 



22 



Par-he Writ* Miss - B est rase Timing 



States 



MMU 



Cache Tag 
Mot 



VA Mot- 



MUX Sel 
VAR / VA 



Cache Miss 
Read 



Tronlate CPU 
Vlrt.Addr. 



I I I I 



Translate Cache 
Virt. Addr. 



Trenlote CPU 
Virt. Addr. 



L Cache J 

P~ TagO.E. ~~ 



CPUVAO.E. 



Updete 
Taps 



Updete 
Tag 
Vol Id 



I Cache I Clk 
Hit/ Tog VA 
Miss? to VAR 



MUX Sel CPU VA 



Clk RA 
toRAR 



(to VAR | 



Clk RA 
to RARl 



MUX Sel VAR 



r- cpu -M k— 
Write OE 



Cache Data O.E. 



Clk 




WrtBk 




Bfr; 




Invert 




Adr A3 





Clk 
WrtBI 
Bfr; 
Invert 
Adr A3 1 



(Merge CPU Data with Data Reg) 
-*| CPU Write 0E|*- • 
Data Reg O.E, * 



Clk 

Data 

Reg 



Update 


Clk 


Update 


Data 


Data 


Data 


Cache; 


Reg 


Cache 


Invert 






Adr A3 







CPU Bus 

Intrtfac8 

Cntls 



Adr Strobe 

| Retry 
to 

CPU 



CPU 
Adr Strobe 



Ack 
to 
CPU 



FIG. 8 



14/23 



parhP Read f 11 ^ ~ Re< ^ rase Timing 



States 



MMU 



Tranlate CPU 
Vtrt.Addr. 



Translate Cache 
Virt.Addr. 



I I 

Tranlate CPU 
Vlrt.Addr. 



Cache Tag 
Mgt 



VA Mgt. 



MUX Sel 
VAR / YA 



Cache Miss 
Read 



h Cache J 
Tag O.E. *| 



CPU VA O.E. 



I Cache I Clk 
Hit/ Tog VA 
Miss? to VAR 



MUX Sel CPUVA 



Clk RA 
toRAR 



Update 
Tags - 



rcpu -+\ k— 
ReadOE 



Cache Data O.E. 



Update 
Tag 
Valid 



Clk 
ICPUVAj 
to VAR 



Clk RA 
I to RAR 



MUX Sel VAR 



Clk 
NVrtBk 

Bfr; 
Invert 
!Adr A3 



Clk 
IWrtBk] 
Bfr; 
Invert 
■Adr A3 1 



-*| CPU Read C€ |*- 
Data Reg O.E. ~ 



Clk 


Update 


Clk 


Dote 


Dote 


Date 


Reg 


Cache; 


Reg 




Invert 






Adr A3 





Update 
Data 
Cache 



CPU Bus 

Intrtface 

Cntls 



u_ cpu 
Adr Strobe 

| Retry 
to 
CPU 



CPU 
Adr Strobe 



Ack 
to 
CPU 



CPU 
Latch 
Data 



FIG. 9 



15/23 



12 



10480 



film* Read C ucle 

f 

Nti B«s (63:0) 

CPU Controls 

Addr Strobe 



Memor y! Data Bus 

From CPU From Mem 



From Mem 



— < Clr(27 0^ < ^Pata (64^ — < ^Data (64)^ 



Data Ack 0 

Data Ack 1 
Memory Controls 
Artdr Ack 

Data Strobe 0 

Data Strobe 1 

Write Beck C ucle 
Data Bus (63:0) 

CPU Controls 

Mem Busy 

Addr Strobe 

Data Strobe 0 

Data Strobe 1 
Memory Controls 
Addr Ack 



f 



FIG. I0a 



From CPU 



From CPU 



From CPU 



^Addr (27 0^ > ^^ta^64)^- ^ Data (64)^ 



r 



r 



\ r 



\_/ 



Data Ack 0 



\ 



Data Ack 1 — 

ttote: All Control Signals are Negative Active Signals 



FIG. 10b 



16/23 

Cache Flush Block Diagram 



2210480 



CPU Bus Grant 



CPU VA(31:28) 
CPU Func Code (2:0) 
Cycle Decode Timing 



CPU 0(1:0) 




CPU A(27:9) 



FIG. II 



Segment Match 
Page Match 
Context Match 



Cache Controls 
Memory Busy 



Comman d Decode 



Bus Request 
Logic: 

CPU Grants Bus 
Mastership 
to Start Flush 
State Machine 



Flush Adr Reg 



52 



T 



+1 



50 



A(8:4) 




Page 
Flush 



Segment 
Flush 



Flush Controls 



Bus Request to CP 
Bus Grant Ack to CI 



Flush A(27:9) 



Flush A(8:4) 



Flush Controls 



17/23 



yj rt.ial Addre «« Cache: 
C ache Hit and Flush Match Definition 



Cache Address 

VA(15:4) 

Cache Tags 

CX(2:0) 

VA(27:17) 

VA(16) 

Valid 

Supvsr Prot 

Flush Address 

VA(15:4) 

CX(2:0) 

VA(27:17) 

VA(16) 





Contex 

Flush 

Match 




E> 



Segme 

Flush 

Match 



Page 
Flush 
Match 



FIG. 1 2 



18/23 



22^0480 



Flush State Machine: 
Flush Command Decode and DVMA State Machine 





State (c) 



1 Request? 






1 *1 

1 


r* 

f 




Assert Bus Request to CPU j 


1 




N ^-"bus Grant^s^ Y 



from CPU' 



Latch Flush Addr and 
Tgpe of Flush Cmd 
Assert Bus Request to CPU 
Assert Bus Acknowledge ' 
to CPU to end cycle 
Assert Flush Request 



State (e) 



Assert Bus Grant Ack to CPU 
Dcassert Bus Request 



^Etfcer Teatjf 



FIG. 13a 



19/23 



Flush Stote Mochine: 
DVMA St»** Mftr.hine con't 



( Goto \ 
\ Ether TestJ" 




Assert Flush Go 
Assert Bus Grant Ack to CPU 



Assert Bus Grant Ack to CPU 
Perform Ethernet Bus Cycle 





Assert Flush Go 
Assert Bus Grant Ack to CPU 



Goto 
DVMA Req> 



Assert Bus Grant Ack to CPU 



FIG. 13b 



20/23 



221C4E0 



Flush State Machine: 
Flush Compare State Machine 




Assert Flush Request 
Initialize Flush S/M: 
Set Incr Count = 0 
for Start Address 
Set Flush Base Adr = 
Fl ush Cmd Address 
Set Adr bit A3 = 0 



^Goto (ga)^ 




Incr Cnt=Incr Cnt+ 1 
Flush Ad r= Base Adr+lncr 
Assert Cache Tag OE 
Assert CPU'WriteOE 



Assert Cache Tag OE 
Assert CPU Write OE 



State (a) 



Assert Cache Tag OE 
Assert CPU Write OE 



State (c) 



FIG. 13c 



21/23 

Flush Slate Machine: 
F1u9h Match State Machine 



2210480 




( Got© ^| 
I (Idle) J 



Assert Cac 


he Data OE 


1 


f 



MUX: Sel VAR 
Translate Cache VA 
Assert CPU VA OE 
Assert Cache Data OE 
CI k Write Back Buffer 
Set Adr bit A3=1 



MUX: Sel VAR 
Translate Cache YA 
Assert CPU VA OE 
Negate Valid Tag 
Assert Cache Data OE 



State 
(qn) 



State (g) 



State (1) 



State (k) 



MUX: Sel VAR 
Translate Cache YA 
Assert CPU YA OE 
Assert Cache Data OE 
CI k Write Back Buffer 
Set Adr bit A3=0 



I 



MUX: Sel VAR 
Translate Cache YA 
CI k Adr to RAR (at p) 
Assert CPU YA OE 



Assert Write Back Req 
(to Flush ReqS/M) 



Assert Memory Busy 
Assert Start Write 
Back Cycle 



C Goto ^ 
^ (Idle) J 

FIG. 13d 



State (m) 



State (o) 



State (q) 




State (s) 



22/23 



221041 



Flush Stote Mochine: 
Flush Comn»rp State Mochine,^orTt 




Assert Flush Request 
Awrt Flush Done 



FIG. I3e 



23/23 



2210480 



rarhe F1u«th- Flush Mf» trh Timing 



States 



MMU 



Cache Tag 
Mot 



VA Mot. 





Cache 


■> 




Teg O.E. 




Incr. 




Flush 


Clk 


Flush 




Match 


TagVA 


Count 




? 


toVAR 




Translate Cache_ 
Vlrt. Addr. 



CPU VA O.E. 



-1 



Clk RA 
toRAA 



MUX Sel 
YAR / VA 



Cache Flush 
Match - Load 
Write Back Bfr 



- CPU 
Write OE 




M OX Sel VAR 




Cache Date O.E. 



Clk 
WrtBk 

Bfr; 

Set 
A3-1 



Clk 
WrtBk 

Bfr; 

Set 
A3-0 



Set 
Wrt 
Bock 
Req 



Write Back 
Reqd? 
Then set 
Mem Busy; 
Start W/B 



FIG. 14 



1 - 



FLUSH SUPPORT . 0 0^0480 

pTTMT ^RY TVT INVENTION 

This invention is directed to certain hardware and 
software improvements in workstations which utilize virtual 
addressing in multi-user operating systems with write back 
caches, including operating systems which allow each user to 
have multiple active processes. In this connection, for 
convenience the invention will be described with reference 
to a particular multi-user, multiple active processes 
operating system, namely the Unix operating system. 
However, the invention is not limited to use in connection 
with the Unix operating system, nor are the claims to be 
interpreted as covering an invention which may be used only 
with the Unix operating system. 

in a Unix based workstation, system performance may be 
improved significantly by including a virtual address write 
back cache as one of the system elements. The present 
invention describes an efficient scheme for supporting data 
protection and the reassignment of virtual addresses within 
such a system. The invention features support for multiple 
active processes, each with its own virtual address space, 
and an operating system shared by those processes in a 
manner which is invisible to user programs. 

Cache "Flush" logic is used to remove selected blocks 
from the virtual cache when virtual addresses are to be 
reassigned. If a range of addresses (a virtual page 
address, for example) is to be reassigned, then all 
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instances of addresses from vithin this range must be 
removed, or "f lushed", from the cache before the new address 
assignment can.be made. A cache block is "flushed" by 
invalidating the valid bit in its tags and writing the block 
back to memory, if the block has been modified. The "Flush- 
logic includes logic to identify "Flush" commands vithin 
"Control Space"; logic to match particular virtual address 
fields, within a Flush command, to corresponding virtual 
address fields either within the cache's block address space 
or its tag virtual address field; and (optional) logic to 
flush multiple cache block addresses as a result of a single 
"Flush" command issued by the CPU (or DVKA device, if 
allowed) . It also includes logic to invalidate the cache 
valid tag on matching cache blocks and logic to enable 
modified matching blocks to be written back to memory. 

The present invention includes both hardware and 
specific "Flush" commands inserted within the operating 
system kernel. 

pT?TKF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the main components 
of a workstation utilizing virtual addresses with write back 
cache . 

Figure 2a is a schematic diagram of cache "hit", logic 

25. 
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Figure 2b is a schematic diagram of a circuit for 
detecting a cache protection violation. 

FigurB 2c is a schematic diagram of a circuit fcr 
detecting a KKU protection violation. 

Figure 3 is a detailed block diagraa showing the 
address path utilized by the virtual addres 3 cache of the 
present invention. 

Figure 4 (4(a), 4(b)) is a flow diagram of a state 
machine implementation for certain controls related to the 
addressing of a virtual address write back cache. 

Figure 5 is a detailed block diagram _ showing the data 
path utilized by the virtual address path of the present 
invention. 

Figure 6 (6a, 6b, 6c and 6d) is a floui diagram of a state 
machine implementation for certain controls related to data 

transfers to and from a virtual address write back cache 
(states (a) - (o) ) . 

Figure 7 is a flow diagraa of a state machine for 
implementation for controlling Write Back bus cycles to 
memory. 

• Figure 8 is a timing diagram for best case timing fo 
a cache write miss. 



Figure 9 is a timing diagram for best: case timing for 
a cache read miss*- 

Figure 10a is a timing diagram of the memory bus cycle 
for performing a block read cycle. 

Figure 10b is a timing diagram of the memory bus cycle 
for performing a write back cycle. 

Figure 11 is a schematic diagram showing the cache 
flush implementation of the present invention. 

Figure 12 is a schematic diagram showing the logic for 
detection of Context Flush Hatch, Segment Flush Match and 
Page Flush Hatch. 

Figure 13 (13a - 13e) is a flow diagram of a state 
machine implementation of a cache flush initiated by the 
issuance of a flush command. 

Figure 14 is a timing diagram for a cache flush. 

DETAILED DESCRIPTION OF THE TNVEHTIQN 

Figure 1 shows the functional blocks in a typical 
workstation using virtual addresses in which the present 
invention is implemented. 

Specifically, such a workstation includes a 
microprocessor or central processing unit (CPU) 11, cache 
data array 19, cache tag array 23, cache hit comparator 25, 



memory management unit (KMU) 27, »ain memory 31, write back 
buffer 39 and workstation control logic 40. Such 
workstations Bay, optionally, also include context ID 
register 32, cache flush logic 33, direct virtual memory 

access (DVKA) logic 35, and multiplexor 37. 

in the present invention, various changes are made to 

cache flush logic 33, cache hit comparator 25 and 

workstation control logic 4 0 which improve the performance 

of a virtual address write back cache. 

p < r +^r, of Ke ^",rv Elemnntr of Workstation 

CPU 11 issues bus cycles to address instructions and 
data in memory (following address translation) and possibly 
other system devices. The CPU address itself is a virtual 
address of (A) bits in size which uniquely identifies bytes 
of instructions or data within a virtual context. The bus 
cycle may be characterized by one or more control fields to 
uniquely identify the bus cycle. In particular, a 
Read/Write indicator is required, as well as a "Type" field. 
This field identifies the memory instruction and data 
address space as well as the access priority (i.e., 
"Supervisor" or -User" access priority) for the bus cycle. 
A CPU wiich may be. utilized in a workstatio'n having virtual 
addressing and capable of supporting a multi-user operating 
system is a MC68020. 
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Another necessary element in a virtual address 
workstation with write back cache shown in Figure 1 is 
virtual address cache data array 19, which is organized as 
an array of 2* 'blocks of data, each of which contains 2* 
bytes. The 2* bytes within each block are uniquely 
identified with the low order M address bits. Each of the 
2 K blocks is uniquely addressed as an array element by the 
next lowest K address bits. As a virtual address cache, the 
(K+M) bits addressing bytes within the cache are from the 
virtual address space of (A + C) bits. (The (C) bits are 
context bits from optional context ID register 32 described 
below.) The (N+M) bits include, in general, the (P) 
untranslated page bits plus added virtual bits from the 
(A+C-P) bits defining the virtual page address. 

Virtual address cache data array 19 described herein is 
a "direct mapped" cache, or -one way set associative- cache. 
While this cache organization is used to illustrate the 
invention, it is not meant to restrict the scope of the 
invention which may also be used in connection with multi- 
way set associative caches. 

Another required element shown in Figure 1 is virtual 
address cache tag array 23 which has one tag array element 
for each block of data in cache data array 19. The tag 
array thus contains 2* elements, each of which has a Valid 
bit (V), a Modified bit (M), two protection bits <P) 
consisting of a Supervisor Protect bit (Supvsr Prot) and a 
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Write Allowed bit, and a virtual address field (VA, and 
optionally CX) as shown in Figure 3. The contents of the 
virtual address field, together with low order address bits 
used to address the cache tag and data arrays, uniquely 
identify the cache block within the total virtual address 
space of (A+C) bits. That is, the tag virtual address field 
oust contain ((A+C) - (M+N) ) virtual address bits. 

Cache "Hit" logic 25 compares virtual access addresses 
with the contents of the virtual address cache tag address 
field. Within the access address, the lowest order M bits 
address bytes within a block; the next lowest V bits address 
a block within the cache; and the remaining ((A+C) - (M+N) ) 
bits compare with the tag virtual address field, as part of 
the cache "hit" logic. 

The cache "hit" logic must identify, for systems with a 
shared operating system, accesses to user instructions and 
data, and to supervisor instructions and data. A "hit" 
definition which satisfies these requirements is illustrated 
in Figure 2a which comprises comparators 20, Aim gate 22, O* 
gate 24 and AND gate 26. 

MMU 27, which translates addresses within the virtual 
space into a physical address, is another required element. 
MMU 27 Is organized on the basis of pages of size (2?) 
bytes, which in turn are grouped as segments of size (2S) 
pages. Addressing within a page requires (P) bits. These 



(P, bit. are physical address bit. vhioh retire no 
delation. The role of wa « i. « the virtual 

pBge address bits «*«-« « <>- P » ln " Phy£lMl Pa5C 
egresses of <MH) bits. The opposite physical address i« 
then (MX) page a^ess bits with (P) bits per page. 

„,„ „ is also the locus for protection cheeking, i.e., 
comparing the access bus cycle priority vith the protection 
e.elaned to the page. To illustrate thi. point, there are 
tvo types o£ protection that may be assigned to a pane 
namely, a Supervisor/User access designator and a Write 
Pr ote=t/«rite Allowed designator. Although the subject 
invention is not lifted to such types of protection, given 
this pace protection, a "Protection Violation" can result if 
either a "User" priority bus cycle accesses a page with 

■ „ jm _ iiwrite" bus cycle accesses 

"Supervisor" protection; or if a Write bus y 

a page vith a "Write Protect- designation. 

The application of KMU protection checking through the 
KKU lB shown in Figure 2c which comprises inverter 28, AHD 
ga tes 30a and 30b, OR gate 34 and AKD gate 36. In addition, 
vith a virtual address write back cache, the concept of 
protection checking can be extended to cache only CPU .cycles 
vhich do not access the KMU. Such cache only protection 
iogic is shown in Figure 2b comprising inverter 42, AKD 
gat es 44a and 44b, OR gate 46 and AND gate 48. 
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Also shown in Figure 1 is main memory 31 vhich is 
eddressabla within' the physical address space; control or 
main memory access is through workstation control logic 40, 

Write back buffer 39 is a register containing one block 
of cache data loaded from cache data array 19. Write back 
buffer 39 is loaded whenever an existing cache block is to 
be displaced. This may be caused by a need to update the 
cache block with new contents, or because the block must be 
flushed. -In either case, in a write back cache, the state 
of the cache tags for the existing cache block determine 
•uhether this block must be written back to memory. If the 
tags indicate that the block is valid and modified, as 
defined below, then the block contents must be written back 
to memory 31 when the cache block is displaced. Write back 
buffer 39 temporarily holds such data before it is written 
to memory. 

Workstation control logic 40 controls the overall 
operation of the workstation elements shown in Figure 1. in 
the preferred embodiment, control logic 40 is implemented as 
several state machines which are shown in Figures 4, 6, 7 
and 13 as will be described more fully below in conjunction 
with the description of cache flush logic 33, portions of 
vhich aje also, in the preferred embodiment, integrated into 
the workstation control logic. 

Description of Opti onal Elements of Workstation 
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context ID register 32 is an optional external address 
register vhich contains further virtual address bits to 
identify a virtual context or process. This register, 
containing C bits, identifies a total of (2-C active user 
processes; the total virtual address space is of size 
2**(A+C) 

*n important component in this virtual address space of 
2 *. (A+ C) bits is the address space occupied by the operating 
system. The operating system is common to all user 
processes, and so it is assigned to a common address space 
across all active user processes. That is, the .(C) context 
bits have no meaning in qualifying the addresses of pages 
vithin the operating system. Rather, the operating system 
is assumed to lie vithin a common, exclusive region at the 
top of the (a«X) bytes of virtual address space for each 
a etive context. Ho user pages may lie within this region, 
so the operating system page addresses for two distinct user 
processes are identical, while the user pages for the two 
processes are distinct. All pages within the operating 
B ystem are marked as having -Supervisor" protection. 

cache flush logic 33 is also an optional element in a 
vorHstation. However, cache flush logic 33 is included, and 
.edified as described in detail below in order «6 improve 
the performance of a virtual address, write back cache 
system. Briefly however, cache flush logic 33 operates as 



follows. If a range of addresses (a virtual page address, 
Cor example) is to be reassigned, then all instances of 
addresses from within this range must be removed, or 
-f lushed", from the cache before the new address assignment 
can be made. A cache block is "flushed- by invalidating the 
valid bit in its tags and writing the block back to memory, 
if the block has been modified. 

In addition to CPU 11 as a source of bus cycles, the 
workstation may include one or more external Input/output 
(I/O) devices such as DVMA logic 35. These external I/O 
devices are capable of issuing bus cycles which parallel the 
CPU in accessing one or more "Types" of virtual address 
spaces. The virtual address from either the CPU 11 or DVMA 
logic 35, together with the address in context ID register 
32, is referred to as the access address. 

Another optional element is data bus buffer 37, which 
in the preferred embodiment is implemented as two buffers to 
control data flow between a 32 bit bus and a 64 bit bus. 
Such buffers are needed when the CPU data bus is 32 bits and 
the cache data array data bus is 64 bits. 

r .-„,< r M .n ^ Blei r ™-. Tinimie to th* Invented Workstation 

in the present invention, the definition of a cache 
"Hit" is modified to take into account the use of a shared 
operating system across multiple active user contexts, and 
the access priority and page protection. By so doing, an 



efficient indication of a protection violation vithin the 
vrlte bacX virtual address cache can be achieved. 
Specifically, to iapLnent the protection definition 
presented above, the following cache "Hit" definition is 
utilized. 

A cache "Hit" has three requirements: 

1) The cache block must be marked as having valid 
contents . 

2) ignoring the (C) context bits, the access virtual 
address bits (A-(K+M>> »u«t match the corresponding tag 
virtual address field bits (A- (N+M) ) , at the cache 
block addressed by the (H) bus access bits. 

3) Either the (C) bits of the access context ID must 
B atch the corresponding (C) context bits in the cache 
tag virtual address field, or the cache tag Supervisor 
protection bit must be set active. 

This definition of a cache "Hit" enables cache 
protection checking to be applied directly to the virtual 
address cache, rather than defined through an KMU check 
during cache miss handling. X "Protection Violation" on a 
cache "Hit" results: 

1)" if the access bus cycle has "User" priority and the 
cache block has "Supervisor" protection; or 



2) if the access is' a Write bus cycle and the cache 
block has Write Protection. 

An implementation of cache hit detector 25 according -to the prese 
invention is shown in Figure 2a described hereinabove. 

The present invention utilizes a set of "Flush" 
commands in the Control Space to efficiently implement 
virtual address reassignment in a virtual address vrite back 
cache. 

In general, Flush commands are bus cycles in Control 
Space which specify, for each unique type of FlUBh command, 
one or more virtual address fields to be compared vith . 
corresponding virtual address fields. In the- virtual address 
cache tags. ' "Matching" address fields cause the hardware to 
"flush" the cache block. To ".flush" the cache block means 
that: 

1) X matching cache block that is marked as both 
"Valid" and "Modified" is written back to memory. This 
requires a cache block "write back" bus cycle to the main 
memory. A "write back" bus cycle writes the contents of an 
entire cache block into main memory at the appropriate 
physical address. As a part of this cycle, the virtual 
address. identifying the cache block is translated through 
the KMu'into a physical memory address. During this 
translation, protection checking for the cache block is 
inhibited. The address translation through the MMU is 



completed prior to returning control to the processor at the 
conclusion of the flush command. 

2) Any matching cache block that is "Valid" , whether 
"Modified" or not, is marked as invalid. 

As described, the "write back- bus cycle requires the 
translation of the cache block virtual address into a 
physical address. The concept of the flush command and 
"write back" bus cycle can also be extended to virtual 
address caches which contain both virtual address and 
physical address tag fields. If a physical address tag 
field is present, no translation is required at the time the 
"write back" bus cycle to main memory is performed. 
However, the present invention is directed to the use of 
virtual address tags to support a virtual address write back 
cache . 

The flush command as described above applies to a 
single cache block. The application of the flush command 
can also be extended so that a single flush command 
activates hardware which checks multiple cache blocks, 
flushing those blocks which match the address fields of the 
flush command. It is only required that the address 
translation of the last cache block flushed be concluded 
prior to returning control to the processor at the 
conclusion of the command. 



Three specific flush commands are defined below. While 
other similar commands »ay be defined, these three are 
particularly useful in effectively restricting the scope of 
a "Flush" command to a minimal address range. These "Flush" 
commands are also effective in implementing a multiple 
context, shared operating system address space. 

1. Context Match Flush Command 

The Context Match Flush command flushes from the cache 
all cache blocks within a specified context which are from 
User protected pages. It specifies a context identifier of 
(C) bits. The match criteria is to require first, that the 
cache tags identify the block as having User protection; and 
second, that the (C) bit field of the Flush command match 
the corresponding (C) bit Context identification field of 
the tags. 

The Context Match Flush command is used to ensure cache 
addressing consistency whenever a new active context 
replaces an old context in the MMU. The Context Match Flush 
must be performed before the old context references are 
removed from the MMU, since the MMU is required to translate 
the cache blocks 1 virtual addresses. 

2. -Page Match Flush Command 

The Page Match Flush command flushes from the cache all 
cache blocks within a specified page, regardless of the page 
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protection. It specifies a page address of (A+C-P) bite. 
The match criteria is to require that tint, the (A-P) bit 
field cf the Flush command, vhich identifies a virtual page 
address vithin a Context, Batch the corresponding (A-P) bits 
to identify the virtual page address of a given cache block. 
These (A-P) bits may be in the cache tag virtual address 
field or in a combination of both the cache access address 
and the cache tag virtual address field, depending on the 
page size and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active, "or ii) the 
context ID register of (C) bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Page Match Flush command is used during page 
management to purge all references to a virtual page - with 
either Supervisor or User protection - from the cache. It 
n ust be performed before the KMU is updated to remove the 
page, since the MMU is required to translate the cache 
blocks' virtual addresses. 

3. segment Match Flush Command 

The Segment Match Flush command flushes from the cache 
all cache blocks within a specified segment, regardless of 
the page protection. It specifies a segment address of 
((A + C)-(P+S)> bits, since the segment site is (2**S) pages. 



The natch criteria is to require that first, the (A-(P+S)) 
bit field of the Flush command, which identifies a segment 
within a Context, Batch the corresponding (*A-(P+S)) bits 
identifying a segment for a given cache block. These <A- 
(P+S)) bits aay be in the cache tag virtual address field or 
in a combination of both the cache access address and the 
cache tag virtual address field, depending on the segment 
sire, the page size, and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active; or ii) the 
context ID register of (C) bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Segment Match Flush command is used during page 
management to purge all references to a virtual segment - 
with either supervisor or User protection - from the cache. 
It may be required, depending on the structure of the HKU, 
whenever the pages of an entire virtual segment must be 
reassigned to a new virtual segment. It must be performed 
before the KMU is updated to remove the segment mapping, 
since the MMU is required to translate the cache blocks' 
virtual addresses. 1 

Flush Command Usage 

The three "Flush" commands defined above, together with 
the respective "match" criteria, are executed only by the 
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operating system vithin the Unix kernel. The placement of 
flush commands within the kernel is described vithin 
Appendix A. By proper placement of "Flush" commands within 
the kernel, virtual address reassignment for a Unix system 
may be implemented to support a virtual address write back 
cache. 

The set of flush commands defined above, when used in 
the Unix kernel as shown in Appendix A, implement a 
mechanism to support virtual address reassignment, as 
required by a virtual address cache, for a Unix system with 
multiple active contexts and an operating system shared 
across those contexts for workstations having either write 
through or write back caches. 

The flush commands,, vhen used in the Unix kernel as 
shown in Appendix A, support a virtual address write back 
cache vithin a Unix system so that the use of such a cache 
is transparent to user application programs. No changes are 
required -to user programs to take advantage of the memory 
speed improvements inherent in a virtual address write back 
cache. 

Additionally, the flush commands, when used in a Unix 
kernel as shown in Appendix A, support a virtual address 
write back cache implementation which contains only a 
virtual address tag field for block identification, not a 
physical address tag field. Avoiding the addition of a 



physical address tag field minimizes the number of cache 
tags required for the virtual address write back cache. A 
write back cache requires that at some point, any cache 
block which has been modified must be written back into main 
memory. This -write back" operation may take place either 
when the cache block is replaced by new block contents (the 
normal block replacement on a cache "miss"), or when the 
cache block is flushed prior to reassigning a range of 
virtual addresses containing this cache block. 

If the cache tags contain no physical address field, 
then the virtual address tags must be translated into a 
physical address before the cache block may be written into 
memory. In the case of cache flushes, this implies that all 
address translations of cache block virtual address fields 
which result from a flush match must be completed prior to 
the operating system's reassignment of the virtual address 
range within the KMU. Two features of the invention are in 
part responsible for ensuring that this requirement is met: 

1) first, that the flush command requires the 
completion of the cache block virtual address translation 
before control is returned to the processor; 

2) and second, that the flush commands are structured 
in the kernel, as shown in Appendix A, at strategic 
locations which guarantee .the flushing of all modified cache 
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blocks prior to the reassignment of the virtual address 
range. 

The set of three flush. commands defined above, together 
with .their respective "match" criteria, constitute an 
efficient virtual address reassignment aechanism vhen placed 
in the Unix kernel as ohown in Appendix A. The mechanism is 
efficient in that it optimizes flush performance for the 
virtual address write back cache for the three cases of 
virtual address reassignment required by the operating 
system: 

1) whenever an existing active context is being 
replaced by a new context; 

2) whenever MMU limitations require the reassignment of 
a currently mapped segment to a new segment; and 

. 3) whenever a physical page in memory is to be 
reassigned to a new virtual address. 

The three flush commands are defined, together with the 
flush match criteria, to specifically cover each of these 
cases. Flush commands are issued by the kernel by starting 
at a base block address, and then incrementing block 
addresses so as to check every block within a fixed address 
range. -The flush commands as defined are efficient in 
address reassignment for two primary reasons: 
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1) The flush natch criteria restrict the number of 
blocks flushed to be only those blocks which require 
flushing within the flush address range. Other extraneous 
addresses, outside the flush range, are checked but are not 
flushed. 

2) For each of the three cases requiring address 
flushing, the defined flush commands allow the cache to be 
checked with a single pass through the appropriate cache 
block address range* For example, to flush a segment, ev*ry 
page within the segment must be flushed* If a segment flush 
were not implemented, then multiple passes of page flush 
commands with varying page addresses might be required to 
complete the segment flush. 

The preferred embodiment of the virtual address cache 
for the address path is shown in Figure 3 and for the data 
path is shown in Figure 5. Flush control logic in the 
preferred embodiment is implemented as ehowri in Figures 11, 
12, the state machine of Figure 13 and timing diagram of 
Figure 14. A best case timing diagram for writes is shown 
in Figure 8 and for reads is shown in Figure 9. 

In addition to components previously discussed with 
reference to Figure 1, Figure 3 includes virtual address 
register (VAR) 5<+ which stores the current virtual address. 
The elements of the invention appear in Figure 3 are cache 
flush logic 33, the Protection bits (P) in the cache tag 
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«-v ,o,, e >, ™,f C h loaic 2U which is part of cache hit 
array 23, and the flush matcn aogic <■ 

detect log 25. 

Also shown in Figure 5 is data register 61 which stores 
data to be written to or vhich has been read from memory 31 
or cache data array 19. 

in Figures 2, 3, 5, 11 and 12, to avoid unnecessarily 
cluttering the Figures, not all control lines are shown. 
However, the control lines necessary for proper operation of 
the invention can be ascertained from the flow chart of the 
state machines shown in Figures 4, 6, 7 and 13, and timing 
diagrams shown in Figures B-10 and 14. 

in the flow charts, the following abbreviations are 
utilized: 





- multiplexor 45 


Sel 


- select 


VA 


- virtual address 


RA. 


.- real address 


OE 


- output enable 


Ack 


- acknowledge 


Cache Hit? 


- Did cache "hit" logic 25 




detect a cache hit? (Fig 2a) 
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Cache Protect Violation ? - Did control logic 4 0 detect a 

detect a cache protect violation? 
(Fig 2b) 

Memory Busy? - Has Memory Busy been asserted? 
MHU Protect Viol? - Did control logic 40 detect a 

HMU protect violation? 
(Fig 2c) 

RAR - real address register 51 
CLK - clock 
Adr - address 
Mem Adr Strobe - memory 31 address strobe 

VAR - virtual address register 5 4 
Mem Adr Ack? - Has a memory address acknowledge 

been asserted by memory 31? 
Mem Data Strobe 0? - Has memory data strobe 0 been 

asserted? 

Mem Data Ack 0? - Has memory data acknowledge 0 been 

asserted? 
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Kern Data Strobe 1? - Has memory data atrobe 1 been 

'asserted? 

Hem Data Ack 1? - Has memory data acknowledge 1 been 

asserted? 

'dX Write Back Buffer - clock write back buffer 39 
CPU Read cycle? - Xb CPU 11 in a read cycle 
Clk Data Reg - clock data register 61 
Valid and Modified Write - Has control logic 4 0 detected . 
Back Data? valid bit (V) and Modified bit (M) 

Start Write Back Cycle? - Has control logic 40 asserted 

Start Write Back Cycle 

Similar abbreviations are used in the timing diagrams 
of Figures 8-10 and 14- 

The address state machine shown in Figures 4a and 4b 
defines certain of the controls related to the address 
handling portion of cache 19. The cache tags 23 are written 
as valid during state (w) , following a successful transfer 
of all block data from memory 31. The invention is 
integrated through- the inclusion of the Cache Protection 
Violation test following state (c) . If a Protection 
Violation is found on a cache Kit, then the CPU bus cycle is 
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terminated immediately vith a Bus Error response to the CPU. 
The KHU Protection Violation on the translated address is 
performed later, following state (g) . 

The data state machine shown in Figures 6a - 6d define 
certain controls related to the data transfer portion of the 
cache. Again, the invention is supported by including a 
test for the Cache Protection Violation following state (c) . 
The MMU Protection Violation test on the translated address 
is similarly performed in state (g) . 

The write back state machine shown in Figure 7 defines 
the control of the Write Back bus cycle to memory. This 
cycle may be performed in parallel with CPU cache accedes, 
since both the Write Back controls and data path are 
independent of the cache access controls and data path. As 
described below, the "Memory Busy" signal causes the address 
and data state machines to wait until a previous Write Back 
cycle has completed. 

The write cache miss timing diagram shown in Figure 8 
defines the overall timing of a CPU write bus cycle to 
memory which misses the cache. The cache Hit and 
Protection Check occur in cycle (c) in this diagram. 

A part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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into write back buffer 39 in cycles (i) and (m) . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVMA) write cycle, then this cache block 
will be writtten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus timing and the 
Write Back state machine. Figures 10 and 7 respectively. 

The CPU write data is merged with block data 
returned from memory on the first data transfer of a 
Block Read memory bus cycle. During cycles (q) through 
(u) , the CPU Write Output Enable controlling buffers 37 
will be active for only those bytes to be written by 
the CPU, while the Data Register Output Enable 
controlling data register 61 will be active for all 
other bytes. During the second data transfer, cycle 
(v) , the Data Register Output Enables for aU bytes 
will be active. 

The read cache miss timing diagram shown in Figure 9 
defines the overall timing of a CPU read bus cycle to a 
cacheable page in memory which misses the cache. The cache 
Hit and Protection Check occur in cycle (c) in this 
diagram. 

A part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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into write back buffer 39 in cycles (i) and (») . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVMA) vrite cycle, -then this cache block 
vill be vrittten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus Timing and the 
Write Back State Machine, Figures 10a and b and 7 respectively. 

Data is read to the CPU by B imultaneously bypassing the 
data to the CPU through buffers 37 enabled by control signal 
CPU Read Output Enable, active in states (q) through (u) , 
and updating the cache, in state (s) . The memory is designed 
to always return the "missing data" on the first 64 bit 
transfer, of a Block Read memory bus cycle and the alternate 
64 bits on the subsequent transfer. After the CPU read bus 
cycle data is returned, the CPU may run internal cycles 
while the cache is being updated with the second data 
transfer from memory. 

• ' The Memory Data Bus timing shown in Figure 10a and 10b. 
.hows the timing of Block Read and Write Back bus cycles. 
Since the cache block size is 128 bits, each cache block 
update requires two data transfers. As indicated above the 
64 bits containing the data addressed by CPU 11 are always 
returned on the first transfer for Block Read bus cycles. 
The memory Busy" control signal active during the Write 
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Back cycle is used to inhibit the start of the next cache 
Bi8S cycle until the previous Krite Back cycle can complete. 

cache flush logic 33 shown in Figure 11 outlines the 
control and data path of the flush controller. This 
controller implements the cache flush operations of the 
present invention for a system with multiple active user 
contexts and a shared operating system. Cache flush logic 
comprises AND gate 48, flip-flops 49, flush address register 
52, incrementer 50, AND gates 55 and OR gate 58. 

Three flush match signals are used by cache flush logic 
33 to determine whether the addressed cache block is to be 
flushed, corresponding to the three flush match signals are 
three flush commands issued by the CPU. A Flush Match is 
said to occur if: 

' (Context Flush Command.) AND (Context Flush Match Signal) 
OR (Segment Flush Command ) AND (Segment Flush Match Signal) 
OR (Page Flush Command) AND (Page Flush Match Signal) . 
An implementation of such flush match logic is shown in 
-Figure 12 comprising comparators 60, AND gate 62, Inverter 
64, OR gate 66 and AND gates 68. 

Flush control logic 33 involves two distinct phases, 
which are shown as separate sequences in the flush state 
machine' Figure 13. The first phase involves decoding a 
Flush command from the CPU and obtaining bus mastership for 
the Flush Control State Machine. The Flush command is 
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i.eu.d by th. CPU in Control Space (identified by Function 
cod. bite FC(2.0)-0*3>. within control Space, th. four high 
order address bite *(31HB)-0«. indict, the Flush commend. 
Th. address field X(27,0> for th. commend correspond to the 
2* bit virtual address field for data accesses. The Flush 
command data bits 0(1=0) encode the type of flush. After 
th. Flush command ie decoded, th. addr.es field X(27: 9 > is 
latched together vith th. type of flush. X Bus Behest 
• ignal is asserted to the CPU to obtain bus mastership. 

The second phase involves performing DVMX cycles to 
test end flush, if necessary, 32 cache blocXe using cache 
flu.h logic 33 as a =VMX device. Thi. DVHX device addressee 
cache blocks vith the virtual address X<27: 9 > captured from 
th. f lu=h com-and, plus eddrese bit. X(6=4) from an internal 
5 bit flush address counter 50. Each cache bloc* »y be 
Checked in three cycles, vith the three Flush Match signals 
gated by the Flush commend latches 55 to determine a -Flush 
Ketch" condition. X -Flush Match- results in the cache 
bloc* being invalidated and . Modified bloc* being vritten 
to memory through the Vrlte Back state machine. Following 
the conclusion of the 32 block cheek, bus mastership may be 
returned to the CPU. 

Kote that as a DVMA device, the cache flush logic 33 
competes vith other C v«X devices for bus ownership, of the 
possible three DVMX devices, Ethernet (not shown) has the 
highest priority, the cache flush logic 33 .econd priority, 
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and VHEbus devices third.' The flush control state machine 
does not include a complete arbitration description for all 
DVMA devices, ,but rather only logic related to the Flush. 

The cache flush state machine shown in Figure 13 
comprises four interacting machines which control the flush 
operation. These four machines control the decode of the 
CPU Flush command and its application to 32 cache blocks. 
The four machines are described below: 

1) The command Decode machine decodes the Flush command 
executed by the CPU. Upon decoding a Flush command, 
the flush virtual address A(27:9) and the type of Flush 
command are latched. The machine asserts a Bus Request 
to the CPU to obtain bus mastership for the flush state 
machine. It also asserts a Flush Request «ignal to 
activate the DVMA machine, below. 

2) The DVMA machine obtains bus mastership from the 
CPU, as indicated by the CPU's asserting Bus Grant, and 
holds mastership by asserting Bus Grant Acknowledge. 

It arbitrates the Flush with the higher priority 
Ethernet requests. 

3) The Flush Compare machine initializes its address 
co.unter A(8:4) to 0 with the Flush Request. signal. It 
continues to check cache blocks as long as Flush Co is 
asserted by the DVMA machine. When Flush Go is 
deasserted, a Flush Done signal is eet at the 
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conclusion of the current block flush, which signals 
the DVMA machine to grant mastership to the Ethernet 
handler. If a Flush Katch is detected, the Flush Block 
Request signal is asserted to activate the Flush Match 
machine. At the conclusion of the Flush Match machine, 
this machine returns a Write Back Request signal to 
* complete the machine's handling of the current cache 
block. 

A) The Flush Katch machine loads the cache data into 
write back buffer 39, clocks the translated cache 
address in real address register 51, and invalidates 
the cache tags 33. Kote that no protection check is 
performed. At the conclusion, the Write Back Request 
signal is asserted. If the cache block is marked as 
Modified, the Start Write Back Cycle signal is also 
asserted to activate the write back state machine shown 
in Figure 7. 

Figure 14 shows cache flush timing and describes the 
timing of a block flush in the event of a "Flush Match". 
This condition is tested in state (c) . The block is 
invalidated in state (k) . If the block satisfies the "Flush 
Match" and is Modified, then it must be written back to 
memory. A -Start Write Back Cycle" signal is asserted in 
state (s) to begin the Write Back state machine. 
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The kernel changes needed to support the virtual 
address write back cache of the present invention for the 
Unix operating system are shown in Appendix A. 
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3. An Invariant Condition £ ^ h virtual Addree* Cache (callad 

feiJD... 

If an entry i. in the cache, it. capping from virtual 
addSs" t?physieal addr... «n»t be corract. 

This i. • .utfieiant condition for the correctn... of the .y.tam 
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if „. flSh^h. Irf.Sld each. line, before a virtual to phy.ical 
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in their low order 17 bit., i.e. modulo 12BK, a. 
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1) ▼ac_ctx£lueh (> fluahaa the caeha by eon t art -match. It flushes 
all caeha lines whoai eupervlsor bits In the cache tag are off AND vhott 
context id's In each* tag* match that of tha KMU context regieter. 
I.e. It flushes an antira uaar contaxt. .vac etxfluah() la defined in 
aip.i. 

5 > vae_eegflush<eegmentjnumber) fluehee the caeha by eegment-aaatch. 
It fluahaa all cadfce Unas whoae segment addraaa parte < AO, 6-2 7 > in SUK-3) 
of tha caeha tag match "segmentjnumber" aithar from a ktrntl tddreea 
apace or from tha currant user's addraaa space. I.e. it fluahaa aithar 
a kernel eegment or a uaar aagtaant of tha currant near contaxt. 
▼ae_segflueh() ia daflnad In nap. a. 

3) vae_pagaf lush (virtual addraaa) fluahaa tha eacha by page-match. 
It fluahaa all caeha Una a whose paga mddxmum parta (A<13-27> In SUH-3) 
of tha caeha tag match tha page number part of "virtual addraaa* aithar 
froca a karnal addraaa apaca or frocn tha currant user's addraaa apace. 
I. a* it fluahaa aithar a karnal paga or a user paga of tha currant uaar 
context. vac_pageflush() la defined in map. a. 

i 

*> vac_flttsh(virtual_addraaa, number of byte*) fluahaa tha caeha 
iinea whose page addreaa parta (A<13-27> in SOH-3) of the cache taga axe in 
the rangea of ["virtual_eddreea", "virtual addraaa" ♦ "number of bytaa" - 1J ♦ 
It fluahaa theaa line* aithar from a kernel addraaa apaca or ?roo tha 
currant ueer r e addraaa apaca. vac_fluah() ia uaad aithar to flueh laaa 
than a paga, aueh aa from resume (), or to fluah a number of eontiguoua 
pages, euch aa frocn pageoutO. vae_flush<> la defined in sup. a. 

5) vac fluahalK) fluahaa tha antira caeha. It la uaad to fluah 
tha antira cache to the physical memory before we dusp tha physical 
saeaory from dumps ys () . It stay also be uaad aa an debugging tool. 
▼ac_fluahall () la defined in vm^maehdep.c. 

€> vaejiieable_kpage{virtual_address) turna off tha caching of 
a kernel page starting at "virtual address"? Zt la uaad by tha device 
driver xumapO routine to anforce tFa conaiatency of aharing a kernel page 
with uaar pages. vac_dieablejcpage () la defined in vmjaachdep.c. 

7) vec_enabla_kpage (virtual addraaa) turna on the caching of a 
karnal page starting at "virtual_addreee" . If a device driver snap 
routine knows that no mora user pages are aharing a kernel page/ it 
calle vac_enable_kpage () to allow the caching of this kernel paga. 
▼acjenable^kpage () is daflnad in vxn_machdep.c 

TV . Where and how do we fluah the cache ? 

1) We call vac^ctxf lush () from ctxfreeO in vm maehdep.c. 
< CtxfreeO la ealled whan a contaxt ia fread from KMU 
and hanca the mapping of the whole context ia not valid. 
CtxfreeO la called from ctxallocO whan the oldeat 
contaxt la buzspad out of MMU, from ewapout () when a 
proceea la awapped out, from exit() when a proeaaa 

la terminated, and from ptexpand() when thia contaxt 
la given up before ita pte'e are expanded. ) 

2) We call vac_ ctxf luah (> from vrelvm() in vnproce. 

{ Vrelvm() relaaaea tha va reaourcea associated with thia 
procees. Thia will cauae all virtual and physical pagaa of 
the process be released and thus invalidate- all virtual to 
physical mappings of the current context. ) 

3) We call vac_ctxf luah () from expand () in vm_proe.c. 

{ Thia happens when a process la ehrinking and it gives back 
aoc&e virtual memory. ) 

4) We call vac^ctxf luah () from evadvlaeO In kern ss&an.c* 

( Whan the parameter to vadviaef) ia VAjrLUSH,~we invalidate 
all paga table entries of the currant process. X context fluah 
la mora efficient than a number of paga flushea. ) 

5) Wa call vac_eegf luah () f rom prrtegrelease <) in vm maehdep.c 
{ Pmecrelease () la called when a pmeq is taken a way. 



FmegreleaseO can be called by either poegalloeO or 
pmegallocrea 0 . ) 

6) We call vac segflushO from pnagloadO in vm_machdep.c. 

{ A «egment~in the hole is to be freed and eet to SEGINV 
in the segment map* ) 

7) We call vac pageflush {) from pageout () in vmpage.c. 

{ This is when a page is marked invalid by tne pageout 
demon. ) 

8) We call vac pageflush () from ovadviseO in kern_nman.c# 
{ This is wKen ovadviseO marks a page invalid. ) 

9) We call vac pageflush () from mapoutQ of vmjnachdep.c. 
( Kapout () Is called to release a mapping from kernel 
virtual address to physical address. 

Kapout () is called from: 

a) physstrat () when mapping from kernel virtual address to 
user buffer address is released. * 

b) wmemfreeO 

c) cleanup () 

d) ptexpendO to release old page tables. ) 

10) We call vac pageflush () from pagemove () of vmjnachdep.c. 

{ In pagemove () we call vac_pagef lush (to) because the mapping 
of "to* to its physical page is not valid after aetpgmapO call. 
We call vac_pageflpah (f rom) because the mapping of "from" 
to the physical page is not valid after the second 
aetpgmapO call. ) 

11) We call vac pageflush () from nbrelse {) of sundev/mb.c. 

{ This is when aetpgmap(addr, 0) is called to invalidate 
the mapping from DVMA virtual addresses to physical 
addresses. ) 

12) We call vac_fluah() from resume () in vax.a. 

{ At the end of context switch time/ the mapping of the 
outgoing process's u becomes invalid. We should flush 
the outgoing process's u before its u mapping becomes invalid. 
Since context switch happens very frequent, we only flushes 
the user struct and the kernel stack , instead of flushing 
the entire u page. (Resume () is also called from procdupO 
to force an update of u.) } 

13) We call vac_fluah() from ammapO/ munmapO, and nrunm apf d() 
in kern rrman.c. 

{ Virtual to physical mappings of some pages are changed. } 

14) We call vac flushallO from duinpsys 0 of machdep.c to 
flush out the content of the entire vac to physical memory 
in order to dun?> out the physical memory. 

15) There are a number of places where virtual-to-physical 
mappings are invalidated implicitly/ e.g. the pme/pte mapping 
is still valid but this mapping is never used again. We 
must flush the associated portion of cache, otherwise/ when 

a new mapping is set up from this virtual address, the 
cache may contain some lines of the previous mapping. 

a) We call vacjpagef lush () from mbsetup () of sundev/mb.c. 
{ In mbsetup (), the mapping from pte'a to physical 
pages is temporarily (until mbrelaae) replaced by the 
mapping from PVMA virtual addresses. ) 

b) We call vac pageflush {) from dumpsye () of machdep.c. 

1 The last page in the DVMA region is used to map to one 
physical page at a time to dump out the physics! memory. 
Such a mapping is invalid each time after (*dumper) O 
is called. ) 

c) We call vacjpageflushO from physstrat 0 of machdep.c. 
{ In physstrat ()/ "user" pages are doubly mapped to 
the kernel space. We flush these user pages when we set 

up the associated kernel pages. I*ter, these mappings from 
kernel virtual pages to physical pages are invalidated by 
mapoutO/ there these kernel virtual addresses are 
flushed. } 

d) We call vac psaeflushO from oopvseaO of machdep.c. 



{ In copy* eg 0, the mapping from virtual address CXDDR1 
to physical address *pgno* beeooes invalid after copy In <) . 
) 

«r) We call vac_pagef lush 0 froa snrw() of sun3/mem.c. 

( In nmrwO* the napping fro© "vmmap" to a physical addres 

is set up to copy physical data to the user apace. This 

siapping becomes invalid after uiomove(). ) 
£) Me call vac jpagef lush () from page in () In vm_paga.c. 

{ The napping from CADDR1 to physical page pf+i beoomes 

Invalid after bzero()» ) 

g) Ke call v*c_flush() f rom procdup () of vro^proc.c 

to flush the kernel stack and parts of forkutl. 

{ In' procdup Or forkutl sups to"the physical u page 

of the child process through vgetu(). 

Since the napping from forkutl to the physical u page 

of the child becomes invalid when the parent returns frocn 

procdup () # forkutl is flushed before procdup () returns. 

} 

h) Ke call vae_fluah() from newprocO of kern_fork.c 
to flush the* u_* part of vfutl. ~ 

{ in newprocO r in the case of.vfork, vfutl naps to 
the physical page of the child through uaecess 0 • 
This napping is not used anymore after vpassvmO 
is called. ) 

i) Ke call vac_flush{) from swap out O of vn.swap.c 
to flush the u_* part of utl. 

{ In awapout O # napping from utl, which ia either 
xawaputl or xswap2utl, to the physical u page of proc p 
is invalid after proc p is swapped out. } 
3) Ke call vac_fluah<) from awapinO of vm_swap.c 
to flush the u_* part of utl. 

{ In swapinO, napping from swaputl to the physical 

u page of proc p becomes invalid before we return from 

swapinO. ) 

k) Ke call vac_pagef lush () from swapO of vm_awp.e. 

{ The mapping from i-th virtual page of process 2 to 
the physical page is not valid anymore. ) 

1) Ke call vac_flush<) f rom pageout {) of vtnjage.c 
. to flush the* u_* part of puahutl. 

{ In pageout o7" the mapping from puahutl to the physical 
u page of rp becomes invalid after the vtod() call. ) 

hi) Ke call vac flush () from pageout () of vm_page.c to 
flush the cluster of pages to be paged out. 
{ SwapO maps the physical pages of these pages to virtual 
addresses of proc [2] before it calls physstratO* Thus, 
the mappings from the outgoing virtual pages to physical 
pages are to be replaced by those of proc [2] virtual pages 
to these physical pages. Therefore, we flush these pages 
in pageout () before swapO is called. ) 

n) Ke call vac pageflush () from kmcopyO of vm_pt.c. 

{ kmcopyO Is called f rom ptexpand () to "copy" pte's 
from old pte'e to new pte's. It "copies" by napin() 
new pte'a to the physical pages of old pte's. Ke fluah 
old pte'a before new pte's are napped-in. } 

o) Ke call vac_pagef lush () from distpteO of vm_pt.e. 

{ distpteO is called when the pte entries of a shared 
text pte is changed. For example, pageout () changes its 
valid bit to invalid. Since other processes sharing thia 
text page nay have this text psge in the cache, we flush 
out this page for all sharing processes. ) 

p) Ke call vac_flush() from vrelpt () of vnjt.c to flush 
the pte's of the outgoing process. 

{ In vrelpt O , the pages that contains pte's are released 
but napout O is not called. ) 
q) Ke call vac_pagef lush 0 from wlok_unlock of 
sunwindowdev/winlock . c . 



{ in wlok unlock (>, sapping from * 1 » c)t - >lo,t -. u, " -#i-M . 
to the physieal u page of the current process become* 
Invalid if wlock-> lok user Is nonzero. ) 
r) Wo call vac_pegeflush (7 from wlok_done {) of 
asunwindowdev/winlock.o. " 

< Xn wlok done Or the napping from wloek->lok_»aer 
to the physical u page becomes invalid. J 
16) Whe£ protection bit. are changed and the affected portion 
of the cache ahould be flu.hed. Such pi ace • axe* 

a) In ehgprotO of vm maehdep.c, we change the protection 
of te?t page.. We'call vac page flush () there to avoid 
having any entry in the cacKe with different protection 

with the HMD. ^ _ _* t „ n 

b) in aettprocO of . vmjaachdep.c we change the protection 
bits of text pages. We call vac_flush(> to flush 

the text part of the process. (aettprot () is called 
from vm text.c.) 
e) in vac disable kpage {) of vmjnaehdep . c we call 

vScpageflusMT to flush all~cache lines of this page 
before making the page non-cached. 

V. Why don't we flush the cache here? _ ^ 

- hfo-t oTlo-Tng irYIIit eTplaefti where the wping from 
virtual addresses to physical addresses are Ranged but the cache 
i. not flushed. We describe the reasons why cache flushings 

are not J* c ;j»J rv r „ () of ^ ^cndep.c, the virtual to physical 

mappinS of proc p is changed to that of proc q. But, q 
gets whatever in the cache previous belong to p, »o no 

? e ^«Lf : lrJs C c.i!.5 0 by P vpa..pt() to pas- the context of p 

vJa.» P ? O is calle7by vpa.evmO which is called before 
and aft« vf ork (> . vpa.evmO passes the vm "source, and 

ZZfn context of P to q. When vpa..vm() returns, the 
virtSS lo^njsical mapping for thS context is not changed. 
Since the context is also passed, the affected mapping, in 
the cache are still correct, except that now they belong to 
proc" instead of proc p. Therefore, there is no need to 
flush the cache either in ctxpas.O or inypwivm () . > 

2) in vpa.aptO, the virtual-to-physical mapping, of proce.ae. 
-Sp- and -uq- are not changed when vpasspt O returns. 
(Or more precisely, the mapping, are e h *?9«* J**** 0 
the same as the mapping, when vpaa.pt () la entered) . 

3> Xn .wapl) of vm swpTe, i£ -flag" indicate, a dirty page 
* JS.hT the mapping of addr to physical address is replaced 
by that of the i-th page of proc[2]. Since dirty page, 
have been flushed in pigeout <> / there is no need to flush 

4, Xn^gJoaao'of'v^michdep.c, when *pmxp (ctx pmeg [.eg] ) 
} is 17x1 and need, we invalidate pmegfeg). since we did 
either a context flush (in ctxfree () ) or a aegment flu.h 
(in pmegreleaee () ) when we set ctx pmeg [segl to aero, 
thf.T« i. no need to do a segment flush nere. 

I There are only two place, where we aet (.truct context *)-> 
. ctx^g*ng] n to rero! One i. in P~g;£"- « " 
vac^Teg£lu.h(.eg) and set.egmap (.eg, SEGINV). 
The~other place i. in ctxfree () where we call vacjstxf lu.n () 
but don't aet.egmap (.eg, SEGXNV) . 

Hence (struct context *) ->ctxj>meg [segl is wro but MMU 

"gmap is not SEGINV in this case. The reason^ that 

when *pmxp — 0 and Ineed in pmegloadO need, a __ STKV 

•et.egmap(.eg, SEG1KV) ^J^^fV^eeO t"2 
Since we have dons a vac^ctxf lush () in ctxfree (), this 
segment should not have any left-over in the ejehe } 
5) Xn ctxallocO of vm maehdep.c, seteegmapO is called 
} 11 invalidate all mlppinq. from the seoment map. Since 
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ctxfreeO ia called earlier to flush the •ntlre 
context, no lines associated with these segments 
"•inthe cache. Therefore, segment fluahee are »ot 

6) Sn^tSeyncO of m machdep.c,- pteeync {) calle ptnegunload (> 
SiS or'S the mod~bits to pte's and reset the mod bits of 

St ShJn^e check ifanother page in thia pmeg i« <*rty, 

lm check ita pte which remembers the mod bit wae on. 
£ oWt need to flush the aegment becauae pmegunload turn, 
off the mod bits in this pmeg* ^ . . 

7) SnloadpgmapO of map.a aaves ^e referenced and modified 
bits from MMU prae to soft pte and clears these bits in the 
~ Since when we do pageout or avapout, it ia the aoft 
pTTthat SI Seek to decide if a page i. dirty, there is no 
need to flush the cache when the referenced and modified 

6, $„ t pn :gunl5rd(t 8 o C f h -l-chdep.c, « «U •etse^CSEG, 
pnrp-pmeg), unloadpgmapC v, pte, nun) , and "t-a^PjCSEG, 
SMINV)! in unloadpgmapO, "^a* "J* °* J. SJ e t0 

access the pme'e in this aegment. Virtual °5, 
.egment CSEG is not accessed, thus segment CSES doesn t 
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CLAIMS 

.1. in a workstation utilizing a virtual address write back 
cache including a central processor having an address bus and a 
data bus, a cache data array, having a plurality of cache blocks, 
a cache tag array having an array element for each of said cache 
blocks, each of said array elements having a Valid bit, a Modified 
bit and a Supervisor Protect bit, a write back buffer, a memory 
management unit, a main memory, a cache hit detector, a context 
identification register, flush control logic and workstation 
control logic, the improvement wherein said cache hit detector is 
modified to detect cache hits in a shared operating system across 
multiple active user contexts, and wherein said workstation further 
comprises: 

a.) means for reassigning virtual addresses across multiple 
user contexts ; 

b) means for completing a cache block flush operation before 
control is returned to the central processor upon the issuance of a 
flush command, and in each- said flush operation, flushing all cache 
blocks having their associated cache tag array element Valid bit 
set, prior to reassignment of the virtual addresses. 

2. The improvement defined by Claim 1 wherein said modified 
cache hit detector comprises: 

a) means for detecting cache blocks having their corresponding 
cache tag array element Valid bit set; 



b) first means for determining whether for the cache block 
being addressed by the central processor, said cache block address 
having a plurality of access virtual address bits, ©aid access 
virtual address bits match virtual address field bits in a 
corresponding dache tag array element; 

c) second means for determining whether i) for the cache block 
being addressed by the central processor, said caid cache block 
address having a plurality of access context bits, said access 
context bits match context bits in the corresponding cache tag 
array element; and ii) the Supervisor Protect bit is set in the 
corresponding cache tag array element. 

3. The improvement defined by Claim 1 wherein said 
reassigning means comprises: 

a set of flush commands disposed within the shared operating 
system, said flush commands being a context match flush command, a 
page match flush command, and a segment match flush command. 

4. The improvement defined by Claim 1 wherein said flush 
operation completing means comprises: 

a) means for decoding said flush command, said flush command 
being one of a context match flush command, page match flush 
command and segment match flush command; 

b) flush address register means for storing an address 
included in 6aid decoded flush command; 



c) incrementing means for incrementing predetermined address 
bits for combining with the address bits in said flush address 
register means; 

d) flush match means coupled to said decoding means for 
generating a flush match logic signal, 

whereby the issuance of a flush command causes all cache 
blocks having their associated Valid bit set to be flushed prior to 
reassignment of the virtual addresses. 

5. The improvement defined by Claim 2 wherein 6aid detecting 
means comprises a first AND gate having a first input coupled to 
the Valid bit of the array element in the cache tag array 
corresponding to the cache block being addressed by the central 
processor. 

'5. The improvement defined by Claim 5 wherein said first 
determining means comprises a first comparator coupled to said 
address bus and said cache tag array, the output of said first 
comparator coupled to a second input of said first AND gate. 

7. The improvement defined by Claim 6 wherein said second 
determining means comprises a second comparator coupled to said 
context identification register And said cache tag array, the 
output of said second comparator coupled to a first input of an XOR 
gate, a second input of said XOR gate coupled to the Supervisor 
Protect bit in the cache tag array element corresponding to the 
cache block addressed by the central processor. 



n. The improvement defined by Claim ? wherein Baid modified 
cache hit detector further comprises : 

a) a second AND gate having one input coupled to the output of 
B aid XOR gate, a, eecond input coupled to the output of said first 
AND gate and a third input coupled to the output of a third 
comparator whose inputs are coupled to Baid address bus and the 
array element of said cache tag array addressed by Baid central 
processor; 

b) a fourth comparator whose inputs are coupled to said 
address bus and the array element of said cache tag array addressed 
by said central processor, the output of Baid fourth comparator 
being a third input of said first AND gate. 

9 . The improvement defined by Claim wherein said 

decoding means comprises an AND gate coupled to Baid central 
processor and first, second and third flip-flop, having their clock 
inputs coupled to the output of said AND gate and their D-inputs 
coupled to said data bus. 

10. The improvement defined by Claim 9 wherein said 

flush address register means comprises a register which loads 
predetermined bits from the address bus when the output of said AND 
gate is set. 

11. The improvement defined by Claim 9 wherein said 

flush match means comprises first, second and third AND gates, each 
having one input coupled to the Q outputs of said first, second and 



"third flip-flops respectively and a second input coupled to ©eane 
for generating a segment match signal, a page match signal and a 
context match signal, an OR gate having fir6t, second end third 
inputs coupled respectively to the outputs of said first, second 
and third AMD gates, whereby the output of said OR gate ia set when 
ona of said segment, page and context match signals are set and a 
corresponding segment, page and segment command has been decoded. 

12. A workstation substantially as herein described with reference to 
end as illustrated in the accompanying drawings. 



— c. 3 .o v™,c* ofi7l Kich Ho*bo-n London WC1R 4TP. Further copies may b? obiamei The Pawn; Office. 

PuBIUhed 1988 * MuK.p.ex "c^ues •«-. S* ^ Cray. Ken-. Ccr. VB, 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 



' □ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS * , 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCED) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 



